Summary

• Implements a question bridge that forwards Claude's clarifying questions to Telegram as inline keyboard buttons, enabling bidirectional interactive conversations in non-interactive (-p) mode
• When Claude needs user input, it outputs structured [QUESTION] tags instead of using the disabled AskUserQuestion tool. The queue processor detects these, forwards to Telegram, waits for the user's button tap, then continues the conversation via --resume
• Supports single-select, multi-select (with toggle + Done), and free-text "Other" responses

How it works

User sends message → Claude responds with [QUESTION] tag
  → Queue processor writes to queue/questions/
  → Telegram client renders inline keyboard
  → User taps button → answer written to queue/answers/
  → Queue processor reads answer, continues with --resume <sessionId>
  → Loop repeats until Claude stops asking questions

Screenshot

Files changed

Key design decisions

• File-based IPC (not sockets) — matches tinyclaw's existing queue architecture
• wx flag on answer writes prevents duplicate answers from double-taps
• Session ID capture via --output-format json on first call, then --resume <sessionId> for continuations
• Heartbeat files refresh pending message TTL during long question loops (prevents 10-min timeout)
• Graceful degradation — if Claude doesn't use [QUESTION] tags, response flows through as normal text
• Telegram-only — interactive mode only activates for the Telegram channel (which supports inline keyboards)

Test plan

• Build compiles cleanly (npm run build:main)
• Claude outputs [QUESTION] tags with the stronger system prompt
• Inline keyboard renders in Telegram with tappable buttons
• Button tap writes answer and continues conversation
• Multi-turn question loops work (tested 4+ rounds)
• "Other" button triggers free-text mode
• Duplicate tap protection (wx flag)
• Timeout fallback (5-min per question)
• Multi-select toggle + Done

🤖 Generated with Claude Code